A transactional system typically persists data to persistent storage such as a log.
FIG. 1 illustrates such a system, here a messaging system, in accordance with the prior art. A four layered approach is shown. An application 10 residing at layer 1 issues a request, such as a PUT message or a GET message request, through application interface (I/F) 20, to messaging processor 30 at layer 2. Messaging processor 30 then performs an operation in accordance with the application's request. For example, the message processor PUTS a message to queue 40. The message processor also persists the requested operation by issuing a persist request through persistence interface 50 to persistence manager 55 at layer 3. Thus operations on messages (op1 to op7) are held by the persistence manager at layer 3. For a messaging system such operations are likely to include PUTS and GETS, but for a database system such operations may include update, insert and delete requests.
Each operation will, at some point in time, be written by the persistence manager 55 through the storage interface 60 to persistent store (e.g. log) 70 at layer 4. When a commit associated with a set of operations (a transaction) is finally confirmed as having been forced to the persistent store, all operations comprising the transaction are also in persistent storage and the system can guarantee to the application that it is possible to recover that set of operations in the event of a system failure. In other words, whilst the persistence manager is permitted a degree of flexibility about hardening the persistence records describing the operations comprising a transaction, all such operations must be on disk by the time the commit is hardened. At this point, the system returns control to the application 10 and processing can continue. Note, as shown in FIG. 1, transactions may be identified by a transaction id (tid1 to 3).
Forcing data to persistent storage is however an expensive process, in terms of time and processing power.
The idea of an asynchronous commit is therefore known; see, for example, the www site IP.com000031629D. This means that as far as an application is concerned, its request has happened, but in reality the system may force or persist appropriate data to disk at a later time.
IDE disks, for example, provide an option such that under certain circumstances if asked to force data to storage, such forcing is not immediately but is done asynchronously.
The www site raxco.be/pages/info/SuperSpeed-Cache/supercache.htm discloses a lazy write system in which a write flush is performed once every second. This is used to improve performance for write intensive applications.
Asynchronous forcing can however result in consistency problems. If the system fails prior to a force, it is not then possible to be sure of the state of the persistent storage.
In the messaging world it is also possible for the requirements for forcing data to persistent storage to be relaxed. For example a message may be designated as “semi-persistent”. This means that upon controlled shutdown, the system guarantees not too lose data but does not make the same guarantees upon system failure.
All of the above solutions are however predefined by the disk or middleware designer. Customers are not provided with any flexibility. There may be certain circumstances under which a customer is prepared to accept a particular degree of risk which is appropriate to the kind of environment that they are operating in; e.g., reliability may be sacrificed for speed.